Flash emulated eeprom wrapper

ABSTRACT

This relates to a file system, and more particularly to, a file system compatible with multiple types of non-volatile memory for safety-critical embedded systems, such as an Electronic Control Unit (ECU) of an automobile. Some examples of the disclosure include an ECU having RAM and non-volatile memory managed by a file system. In some examples, non-volatile memory can include a flash-emulated EEPROM (FEE) device. A wrapper function can provide an interface between a file system and one or more hardware devices, allowing the file system and application code to be compatible with multiple kinds of hardware.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Patent ApplicationNo. 62/288,938, filed Jan. 29, 2016, the content of which isincorporated by reference herein in its entirety for all purposes.

FIELD OF THE DISCLOSURE

This relates to a file system, and more particularly to, a file systemcompatible with multiple types of non-volatile memory forsafety-critical embedded systems, such as an Electronic Control Unit(ECU) of an automobile.

BACKGROUND OF THE DISCLOSURE

Embedded systems can feature random access memory (RAM), non-volatilememory, and other types of memory and storage within a memory hierarchy.RAM can provide fast performance but can require a connected powersupply to retain data. Non-volatile memory, however, can retain datawhen the power supply is disconnected. Examples of non-volatile memoryinclude, but are not limited to, Electrically Erasable ProgrammableRead-Only Memory (EEPROM), battery-backed RAM, and flash, includingflash-emulated EEPROM (FEE). To create a system that can functionquickly and retain data when the power supply is disconnected, data canbe stored in non-volatile memory and loaded into RAM when it is neededto execute a function. When RAM data is modified, it can later be savedto non-volatile memory to be available in the event of loss of power.When data is saved to RAM or non-volatile memory, it can be accessed bya function that knows the address where the data is saved.

The non-volatile memory in many embedded systems can be managed manuallywithin application code or by a file system. When non-volatile memory ismanaged by application code, developers can agree on which addresses innon-volatile memory to allocate to each data structure. Managing theaddress of each structure prevents data from being inadvertentlyoverwritten or lost. Manually allocating and tracking the contents ofeach level of a memory hierarchy can be error-prone and tedious. Filesystems, however, can automatically manage memory on multiple levels andprovide other features, described below for example, to alleviateseveral disadvantages of manual memory management.

File systems can allocate space for data in multiple levels of a memoryhierarchy within a computer system and maintain a record of where eachstructure is located. Other features of file systems include, but arenot limited to, multi-level directories and the use of securitycredentials. These file systems are advantageous to computersystems—including, but not limited to, mobile devices, laptops, andother consumer electronics—with many files, high-level functions, and/orsensitive data. Electronic Control Units (ECUs) within consumerautomobiles, however, generally run low-level, safety-criticalapplications. Therefore, many features of contemporary file systems areunnecessary for managing memory within an ECU. Furthermore, multiplekinds of memory devices can be included in a single vehicle, thusnecessitating special functionality of one or more filesystems for usein a vehicular file system. For example, different kinds of FEE devicescan be used across different ECUs, each FEE device requiring a libraryof function calls to achieve EEPROM behavior. Thus, there exists a needin the field of ECUs for a file system tailored to automotive controlsequences and ECU hardware, which can vary across ECUs incorporated intoa single automobile.

SUMMARY OF THE DISCLOSURE

This relates to a file system and, more particularly, to a file systemcompatible with multiple types of non-volatile memory forsafety-critical embedded systems, such as an Electronic Control Unit(ECU) of an automobile. Some examples of the disclosure include an ECUhaving RAM and non-volatile memory managed by a file system.Contemporary file systems can be designed to work with specific hardwareimplementations of non-volatile memory such as, for example, EEPROM,flash, battery-backed RAM, or other types of non-volatile memory. Insome examples of ECUs, the hardware used for non-volatile memory may beunknown at the start of software development or may be inconsistentbetween ECUs incorporated into a line of vehicles or even within asingle vehicle, for example. This inconsistency can make it difficultfor a team of developers to select a file system for an ECU and make iteven more difficult to manually manage the non-volatile memory withinapplication code. Furthermore, some examples of file systems candynamically allocate memory. In safety-critical systems such as an ECU,it can be advantageous to only save data when there is sufficient timeto complete the save operation to avoid loss of critical information,for example. In some examples, an ECU can include a hardware-independentfile system designed for safety-critical systems.

In some examples, an ECU can use a file system to manage RAM andnon-volatile memory. In some examples, a file system can providesoftware developers with hardware-independent functions for using thefile system in code to be executed by the ECU. A hardware-independentfile system according to examples of the disclosure can provide a layerof abstraction so developers may not need to tailor their code to thetype of non-volatile memory the ECU uses. According to some examples ofthe disclosure, the file system can include a table of contents havingan array of entries. The array of entries can record and track one ormore data structures that may be stored in RAM and/or non-volatilememory of an ECU, for example. The array can include, for each entry, aunique ID, its address in RAM and non-volatile memory, its size, andmetadata. The metadata can include, for example, a version number, atime the entry was last saved to non-volatile memory, and otherinformation according to examples of the disclosure. When the ECU ispowered on, the table of contents can be loaded from non-volatile memoryinto RAM. Before powering off, the ECU can save the table of contents tonon-volatile memory when it is safe to do so. In some examples, data canbe saved to non-volatile memory in situations where there is enough timeto complete the process of saving without interruption to prevent datacorruption, making the ECU more reliable. Furthermore, one or morewrapper functions can be provided to asynchronously execute read/writeoperations, creating an additional layer of compatibility and protectionfrom inadvertent data loss.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary memory hierarchy according to examplesof the disclosure.

FIG. 2 illustrates an exemplary computing system according to examplesof the disclosure.

FIG. 3 illustrates an exemplary computing system including a file systemaccording to examples of the disclosure.

FIG. 4 illustrates a block diagram of exemplary computing systemhardware managed by a file system according to examples of thedisclosure.

FIG. 5 illustrates an exemplary process for initiating a file system andloading or generating a table of contents for the file system, accordingto examples of the disclosure.

FIG. 6 illustrates an exemplary process for managing a data structureincluding registering an entry, saving an entry, and retrieving an entryusing a file system, according to examples of the disclosure.

FIG. 7 illustrates an exemplary process for saving all entries andsaving the table of contents to non-volatile memory using a file system,according to examples of the disclosure.

FIG. 8 illustrates an exemplary computing system including a file systemand a wrapper function according to examples of the disclosure.

FIG. 9 illustrates an exemplary block diagram of computer hardware witha file system in communication with a FEE wrapper function according toexamples of the disclosure.

FIG. 10 illustrates an exemplary process for initiating a file systemand loading or generating a table of contents for the file system,according to examples of the disclosure.

FIG. 11 illustrates an exemplary process for managing a data structureincluding registering an entry, saving an entry, and retrieving an entryusing a file system, according to examples of the disclosure.

FIG. 12 illustrates an exemplary process for saving all entries and thetable of contents to non-volatile storage using a file system, accordingto examples of the disclosure.

FIGS. 13A-13C illustrate exemplary processes of storing data using awrapper function according to examples of the disclosure.

FIG. 14 illustrates a block diagram of an exemplary vehicle including aplurality of ECUs according to examples of the disclosure.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanyingdrawings which form a part hereof, and in which it is shown by way ofillustration specific examples that can be practiced. It is to beunderstood that other examples can be used and structural changes can bemade without departing from the scope of the examples of the disclosure.

Embedded systems can feature random access memory (RAM), non-volatilememory, and other types of memory and storage within a memory hierarchy.RAM can provide fast performance but can require a connected powersupply to retain data. Non-volatile memory, however, can retain datawhen the power supply is disconnected. Examples of non-volatile memoryinclude, but are not limited to, Electrically Erasable ProgrammableRead-Only Memory (EEPROM), battery-backed RAM, and flash, includingflash-emulated EEPROM (FEE). To create a system that can functionquickly and retain data when the power supply is disconnected, data canbe stored in non-volatile memory and loaded into RAM when it is neededto execute a function. When RAM data is modified, it can later be savedto non-volatile memory to be available in the event of loss of power.When data is saved to RAM or non-volatile memory, it can be accessed bya function that knows the address where the data is saved.

The non-volatile memory in many embedded systems can be managed manuallywithin application code or by a file system. When non-volatile memory ismanaged by application code, developers can agree on which addresses innon-volatile memory to allocate to each data structure. Managing theaddress of each structure prevents data from being inadvertentlyoverwritten or lost. Manually allocating and tracking the contents ofeach level of a memory hierarchy can be error-prone and tedious. Filesystems, however, can automatically manage memory on multiple levels andprovide other features, described below for example, to alleviateseveral disadvantages of manual memory management.

File systems can allocate space for data in multiple levels of a memoryhierarchy within a computer system and maintain a record of where eachstructure is located. Other features of file systems include, but arenot limited to, multi-level directories and the use of securitycredentials. These file systems are advantageous to computersystems—including, but not limited to, mobile devices, laptops, andother consumer electronics—with many files, high-level functions, and/orsensitive data. Electronic Control Units (ECUs) within consumerautomobiles, however, generally run low-level, safety-criticalapplications. Therefore, many features of contemporary file systems areunnecessary for managing memory within an ECU. Furthermore, multiplekinds of memory devices can be included in a single vehicle, thusnecessitating special functionality of one or more filesystems for usein a vehicular file system. For example, different kinds of FEE devicescan be used across different ECUs, each FEE device requiring a libraryof function calls to achieve EEPROM behavior. Thus, there exists a needin the field of ECUs for a file system tailored to automotive controlsequences and ECU hardware, which can vary across ECUs incorporated intoa single automobile.

This relates to a file system and, more particularly, to a file systemcompatible with multiple types of non-volatile memory forsafety-critical embedded systems, such as an Electronic Control Unit(ECU) of an automobile. Some examples of the disclosure include an ECUhaving RAM and non-volatile memory managed by a file system.Contemporary file systems can be designed to work with specific hardwareimplementations of non-volatile memory such as, for example, EEPROM,flash, battery-backed RAM, or other types of non-volatile memory. Insome examples of ECUs, the hardware used for non-volatile memory may beunknown at the start of software development or may be inconsistentbetween ECUs incorporated into a line of vehicles or even within asingle vehicle, for example. This inconsistency can make it difficultfor a team of developers to select a file system for an ECU and make iteven more difficult to manually manage the non-volatile memory withinapplication code. Furthermore, some examples of file systems candynamically allocate memory. In safety-critical systems such as an ECU,it can be advantageous to only save data when there is sufficient timeto complete the save operation to avoid loss of critical information,for example. In some examples, an ECU can include a hardware-independentfile system designed for safety-critical systems.

In some examples, an ECU can use a file system to manage RAM andnon-volatile memory. In some examples, a file system can providesoftware developers with hardware-independent functions for using thefile system in code to be executed by the ECU. A hardware-independentfile system according to examples of the disclosure can provide a layerof abstraction so developers may not need to tailor their code to thetype of non-volatile memory the ECU uses. According to some examples ofthe disclosure, the file system can include a table of contents havingan array of entries. The array of entries can record and track one ormore data structures that may be stored in RAM and/or non-volatilememory of an ECU, for example. The array can include, for each entry, aunique ID, its address in RAM and non-volatile memory, its size, andmetadata. The metadata can include, for example, a version number, atime the entry was last saved to non-volatile memory, and otherinformation according to examples of the disclosure. When the ECU ispowered on, the table of contents can be loaded from non-volatile memoryinto RAM. Before powering off, the ECU can save the table of contents tonon-volatile memory when it is safe to do so. In some examples, data canbe saved to non-volatile memory in situations where there is enough timeto complete the process of saving without interruption to prevent datacorruption, making the ECU more reliable. Furthermore, one or morewrapper functions can be provided to asynchronously execute read/writeoperations, creating an additional layer of compatibility and protectionfrom inadvertent data loss.

Other features of file systems include, but are not limited to,multi-level directories and the use of security credentials. These filesystems are advantageous to systems with many files, high-levelfunctions, and/or sensitive data, for example. In some examples, filesystems are designed to work with a particular type of hardware for eachlevel of memory.

Electronic Control Units (ECUs) within consumer automobiles, however,generally run low-level, safety-critical applications, for example.Therefore, according to some examples of the disclosure, many featuresof contemporary file systems may be unnecessary for managing memorywithin an ECU. Furthermore, in some examples, contemporary file systemscan be hardware-dependent. When, for example, the one or more types ofhardware for non-volatile memory can vary from project-to-project or maynot be agreed on at the start of a project, memory management can bechallenging for developers because different types of non-volatilememory can operate in different ways. In particular, a first FEE devicecan use a first library for emulating EEPROM behavior while a second FEEdevice can respectively use a second library for emulating EEPROMbehavior. File systems according to examples of the disclosure caninclude hardware-independent functions for developers to use whenwriting software for ECUs. In some examples, a file system itself can behardware-independent. A wrapper function can be included to receive oneor more hardware-independent function calls from a file system and tointerface with one or more devices of a computing system.

File systems and associated wrapper functions can be used in computingsystems such as embedded systems, consumer electronics, and computers tomanage data stored thereon, according to examples of the disclosure. Acomputing system can include multiple levels of memory, such as volatilememory (e.g., random access memory (RAM)) and non-volatile memory, forexample. Each level can have tradeoffs associated therewith. FIG. 1illustrates an exemplary memory hierarchy 100 according to examples ofthe disclosure. The memory hierarchy 100 can include multiple levels ofmemory with associated tradeoffs such as speed 120 and cost 130, forexample. In some examples, the memory hierarchy 100 includes storage102, non-volatile memory 104, RAM 106, and a cache 108. Storage 102 canbe implemented in a hard drive, for example. Non-volatile memory 104 canbe implemented in an EEPROM, battery-backed RAM, or flash (including,e.g., one or more FEE devices), for example. Other implementations ofstorage 102 and non-volatile memory 106 are possible. Other exemplarycomputer systems may have more or fewer levels within a memory hierarchyas appropriate for the computer system. Some ECUs can have a memoryhierarchy including RAM and non-volatile memory, for example.

In the example of FIG. 1, the cache 108 is the fastest and mostexpensive level of memory in the hierarchy 100 and storage 102 is theslowest and least expensive. As such, an exemplary computer systemhaving example memory hierarchy 100 can have the least amount of spacein the cache 108 and the most amount of space in storage 102, forexample. By having less space in faster, expensive memory and more spacein slower, inexpensive memory, a computing system can perform at highspeeds when necessary without including excessively large amounts ofexpensive, high-speed memory.

Furthermore, in some examples, volatile levels of the memory hierarchy,such as the cache 108 and RAM 106 may only retain data while a systempower supply (not shown) is connected. Other levels of the memoryhierarchy 100, such as non-volatile memory 104 and storage 102 canretain data while a system power supply is disconnected. Therefore,having multiple levels of memory can, for example, allow a computersystem to retain data when powered off in addition to the othertradeoffs discussed above.

To make effective use of its memory hierarchy, a computer system maymove data between hierarchy levels during operation, for example. Insome examples, when a computer system is executing an application ormodifying a file, it can be advantageous for that data to reside onhigh-speed, high-cost memory such as the cache 108. When the computerhas finished modifying data, the data can be saved to a slower, lessexpensive level of memory, such as non-volatile memory 104 or storage102, for example. In some examples, saving data not currently in use tonon-volatile memory 104 or storage 102 can make room in the cache 108and in RAM 106 for other data and can secure it in the event of a poweroutage. For simple memory hierarchies, such as those including only RAMand non-volatile memory, for example, developers can manually trackwhich addresses in each level of memory a data structure is to be saved.Keeping a record of where each data structure can be saved in each levelof memory can help a team of developers avoid inadvertently overwritingor losing track of data, for example.

In some examples, as mentioned above, one or more software developerscan manually track each data structure included in application code in amemory hierarchy of a computing system. FIG. 2 illustrates an exemplarycomputing system 200 according to examples of the disclosure. Computingsystem 200 can include application code 201 interfacing directly withcomputer hardware 203.

When application code 201 interfaces directly with hardware 203, one ormore developers working on application code 201 can ensure a location inhardware 203 of each data structure used in application code 201 isdocumented and tracked. To reliably manage memory, storage, and otherregisters of hardware 203, the one or more developers may writeapplication code 201 to specifically interact with the type(s) ofdevices included in hardware 203. For example, when writing applicationcode 201 for hardware 203 including a FEE device, the one or moredevelopers can call one or more functions of a respective libraryprovided with the FEE device to properly use it. Accordingly, one ormore developers may know which specific device(s) are in use in hardware203 prior to writing application code 201.

Because application code 201 interfaces directly with hardware 203,every developer writing software for computing system 200 may need toknow what kinds of devices are in use in hardware 203 and/or whichaddresses of one or more devices can be used for each data structure. Insome examples, as memory hierarchies become more complex, as developerteams grow, or as development moves at faster speeds, manually trackingthe location of each data structure can become error-prone and tedious.Furthermore, to manually manage non-volatile memory, developers may needto know one or more specific types of hardware the computer system willuse and how to manage its memory, for example. Therefore, in someexamples, it can be advantageous to further include a file system tointerface between application code and hardware of a computing system.

As mentioned above, a computing system according to examples of thedisclosure can further include a file system to manage memory atmultiple levels, for example. FIG. 3 illustrates an exemplary computingsystem 300 including a file system 305 according to examples of thedisclosure. Computing system 300 can include application code 301, filesystem 305, and hardware 303.

In some examples, file system 305 can allocate space in multiple levelsof a memory hierarchy included in hardware 303 within a system andmaintain a record of where each data structure included in applicationcode 301 is located. In this way, application code 301 can make one ormore memory—and/or storage—management function calls to file system 305,as opposed to interacting with one or more devices included in hardware303 directly. File system 305 can ensure each data structure is storedin a documented location for reliable retention and retrieval inresponse to receiving the above function calls.

In some examples, a computing system (e.g., an ECU included in avehicle) can include RAM and non-volatile memory managed by a filesystem. FIG. 4 illustrates a block diagram of exemplary computing systemhardware 400 managed by a file system according to examples of thedisclosure. Hardware 400 can include RAM 410 and non-volatile memory450, each with data 442 and 492 stored thereon, according to examples ofthe disclosure.

Data in RAM 410 can be addressed by byte number 432 and bit number 434,for example. Data in non-volatile memory 450 can be addressed by bytenumber 472 and bit number 474, for example. In some examples, RAM 410can be faster and more expensive than non-volatile memory 450.Non-volatile memory 450 can retain data even when the power supply (notpictured) to the hardware 400 is disconnected, for example. Non-volatilememory 450 can include EEPROM (including, e.g., a FEE device), flash,battery-backed RAM or other types of non-volatile memory, according toexamples of the disclosure. In some examples, a file system can keeptrack of a location of each data structure used in application code ineach level of a memory hierarchy (e.g., RAM 410 and Memory 450). A filesystem can include hardware-agnostic functions for developers to call touse the file system to save, load, and/or move one or more datastructures, allowing the application code to perform these functionswith a variety of non-volatile memory types. Because RAM 410 andnon-volatile memory 450 can have different advantages and disadvantages,hardware 400 can use both levels of memory to have fast performance andinexpensive memory capable of saving data without a connected powersupply.

As mentioned above, according to some examples of the disclosure, acomputing system including hardware 400 can use a file system capable ofmanaging data in RAM 410 and non-volatile memory 450. The file systemcan include a table of contents, of which there may be a copy 420 savedin RAM 410 and/or a copy 460 saved in non-volatile memory 450. When thetable of contents 420 stored in RAM 410 is updated, as will be describedbelow, and then saved to non-volatile memory 450, both copies 420 and460 can be identical. The table of contents 420 stored in RAM 410 caninclude entries, such as entry 422, that indicate where each datastructure of the ECU is stored in RAM 410 and non-volatile memory 450,which will be described in more detail below. Likewise, for example, thetable of contents 460 stored in non-volatile memory 460 of hardware 400can include respective entry 462.

Entry 422 in table of contents 420 can include a unique ID 421, anaddress 423 of the data structure in RAM 410, an address 425 of the datastructure in non-volatile memory 450, and the size 427 of the datastructure, for example. Likewise, for example, entry 462 in table ofcontents 460 can include a unique ID 461, an address 463 of the datastructure in RAM 410, an address 465 of the data structure innon-volatile memory 450, and the size 467 of the data structure. Asshown in FIG. 4, for example, “frontLights” is stored at address 0x7EFin RAM 410 and address 0x013CF in non-volatile memory 450. Theseaddresses are reflected in entry 422 in table of contents 410 and entry462 in table of contents 460. Some example tables of contents may alsoinclude metadata (not pictured) for each entry. The metadata can includea version number and a time indicating when the entry was last saved tonon-volatile memory. Some examples of the disclosure may, additionallyor alternatively, have other kinds of metadata for each entry within atable of contents.

In some examples, a table of contents, such as table of contents 420 ortable of contents 460 for example, can also include its own metadata(not pictured). This metadata can include an ID to indicate a locationof the table of contents in non-volatile memory, a version indicatingthe structure of the table of contents, a time indicating when the tableof contents was created, and a time indicating when the table ofcontents was last saved to non-volatile memory. Some examples of thedisclosure may, additionally or alternatively, have other kinds ofmetadata for a table of contents.

A file system according to examples of the disclosure can automaticallymanage where in RAM and non-volatile memory to save a data structureonce that data structure is initiated. FIG. 5 illustrates an exemplaryprocess 500 for initiating a file system and loading or generating atable of contents for the file system, according to examples of thedisclosure. An application stored on a computing system can execute acommand to initiate a file system (e.g., the command can originate inapplication code). Once the command is received 510 at the file system,the computing system can check 520 non-volatile memory for an existingtable of contents (e.g., table of contents 460), for example. In someexamples, a table of contents 460 and its entries may have been saved tonon-volatile memory before the ECU power was disconnected. In someexamples, if a table of contents 460 is found in non-volatile memory, itcan be moved 532 to RAM. In some examples, if no table of contents isfound, a new table of contents 420 can be created 534 in RAM. Once thetable of contents (e.g., table of contents 460 stored in memory 450 ortable of contents 420 stored in RAM 410) is moved 532 to, or created 534in, RAM 410, it can be read and edited by the computing system to managedata, according to examples of the disclosure.

In some examples, once a table of contents 420 is stored in RAM, thecomputing system can use the file system to manage data. FIG. 6illustrates an exemplary process 600 for managing a data structureincluding registering an entry 610, saving an entry 630, and retrievingan entry 650 using a file system, according to examples of thedisclosure. For data to be managed by the file system, it can beregistered 610 with a table of contents, for example.

In some examples, registering 610 an entry can include storing an ID 421or 461 of the data structure, its size 427 or 467, and its address inRAM 423 or 463 and/or its address in memory 425 or 465 in a table ofcontents 420 or 460. In some examples, an application executed by thecomputing system can include a command to register an entry. The commandcan include a unique ID 421 or 461 for the entry, the size 427 or 467 ofthe data structure, and a version number (not shown), for example. Whenthe command is received 612 at the file system, the entry can be addedto the table of contents 614 and managed by the file system according toexamples of the disclosure.

In some examples, space in RAM 410 and non-volatile memory 450 can beallocated for each entry at the time it is registered. In otherexamples, space in RAM 410 and non-volatile memory 450 can bedynamically allocated as needed. In some examples, when an entry isregistered to the table of contents 420 or 460, the entry may notinclude an address in non-volatile memory 450 until the application codeexecutes a command to save the corresponding data structure, asdescribed below. Additionally or alternatively, in some examples, datastored in non-volatile memory 450 may not have a RAM address 423 or 463associated therewith until it is loaded from non-volatile memory 450, asdescribed below. Examples of saving and loading data with a file systemaccording to examples of the disclosure will now be described.

In some examples, after registering entries, as described above, thefile system can save 630 registered entries to non-volatile memory 450.Saving data to non-volatile memory 450, as discussed above, can have theadvantages of protecting it in the event of a power outage and/orcreating more space in RAM 410 for data that may need to be edited, forexample. An application executed by the computing system according toexamples of the disclosure can modify data associated with a registeredentry and then execute a command to save it to non-volatile memory 450.Once the command is received 632 at the file system, the data can besaved 634 to non-volatile memory 450, for example. In some examples, anentry may have space allocated for it in non-volatile memory when it isregistered. That is, there may be space in non-volatile memory 450allocated for data that has not yet been saved to non-volatile memory450, for example. In some examples, an entry may not have spaceallocated for it in non-volatile memory 450 when it is registered. Thatis, an entry's address 425 or 465 in non-volatile memory 450 may not beincluded in the table of contents 420 or 460 until the entry has beensaved to non-volatile memory 450, for example.

In some examples, once an entry is registered 610 with the table ofcontents 420 or 460 and saved 630 to non-volatile memory 450, it can beretrieved 650 from non-volatile memory 450 and loaded into RAM 410.Loading data into RAM 410, as discussed above, can have the advantagesof quick access and editing, for example. In some examples, anapplication executed by the computing system can retrieve data to beedited or otherwise used by the computing system by executing a command.Once the command is received 652, the data can be copied into RAM 654,for example. In some examples, an address in RAM may be allocated fordata before a command to retrieve the entry's data is received at thefile system. That is, the table of contents 420 or 460 may alreadyinclude an assigned address 423 in RAM for an entry before it isretrieved, for example. In some examples, an address 423 in RAM may beallocated for an entry when a command to retrieve the entry's data isreceived at the file system. That is, an entry's address 423 in RAM maynot be included in the table of contents 410 or 460 until the entry'sdata has been loaded into RAM 410, for example. According to examples ofthe disclosure, an entry's data can be retrieved as long as the entry isregistered to the table of contents 420 or 460 and its data is saved tonon-volatile memory 450. For example, if a computing system has notsaved or otherwise edited data using its RAM 410 since powering on, itcan access data saved to non-volatile memory 450 during a previous useby retrieving it from non-volatile memory 450.

In some examples, when data is being saved to non-volatile memory 450,an interruption such as a power outage or other error can corrupt thedata. In a safety-critical system such as a vehicle ECU, it may beimportant for saves only to occur when there is enough time to reliablycomplete the process uninterrupted, for example. Therefore, someexamples of the disclosure only save data to non-volatile memory 450when a command to save is received from the user or when the systemotherwise detects there is sufficient time to fully execute the save. Insome examples, to preserve the table of contents 420 and all datacurrently stored in RAM 420, everything can be saved to non-volatilememory 450 before the power supply (not shown) is disconnected. FIG. 7illustrates an exemplary process 700 for saving 720 all entries andsaving 730 the table of contents 420 to non-volatile memory 450 using afile system, according to examples of the disclosure. The computingsystem can receive a command to save everything 710, for example. Then,all entries can be saved 720 to non-volatile memory and the table ofcontents 420 can be saved 730 to non-volatile memory 450, for example.

In some examples, steps 720 and 730 may be performed in any order orconcurrently according to various examples of the disclosure. In someexamples, a command to save everything can be sent to the file systemautomatically in response to a user command to disconnect or turn off apower supply of the computing system. For example, a user may input acommand to turn off a vehicle including one or more ECUs including acomputing system according to the examples described above.

Although a file system according to FIGS. 3-7 can provide a layer ofabstraction between application code and device hardware, the filesystem itself may need to be tailored to one or more specific devicesincorporated into a computing system on which it operates. For example,to perform a save or load operation according to the examples describedabove, the source code of a file system may need to make one or morefunction calls to an EEPROM-emulating library of a FEE deviceincorporated into a computing system. Just as it can be inconvenient fora team of developers working on application code to use device-specificfunction calls to manage memory, it can be inconvenient for a team ofdevelopers maintaining a file system's source code to do the same.Therefore, in some examples, it can be advantageous to further include aFEE wrapper function to provide a standardized, predictable interfacebetween a file system and device hardware.

In some examples, a FEE device can be a flash-based device with memoryaddressable in blocks configured to emulate the individually-addressablebyte behavior of an EEPROM. Several types of FEE devices are available,each with different libraries for accessing EEPROM-like behavior of thedevice. A FEE wrapper function can allow a file system to issueEEPROM-style commands that will be compatible with a plurality of FEEdevices, allowing developers of application code and of the file systemitself to write their source code independent of the type of hardwarethat will be used in a computing system. FIG. 8 illustrates an exemplarycomputing system 800 including a file system 805 and a wrapper function807 according to examples of the disclosure. Computing system 800 caninclude application code 801, file system 805, wrapper function 807, andhardware 803.

In some examples, file system 805 can allocate space in multiple levelsof a memory hierarchy included in hardware 803 within a system andmaintain a record of where each data structure included in applicationcode 801 is located. In this way, application code 801 can make one ormore memory—and/or storage—management function calls to file system 805,as opposed to interacting with one or more devices included in hardware803 directly. In turn, file system 805 can manage data stored onnon-volatile FEE devices by making EEPROM-style function calls towrapper function 807, which can interface with hardware 803. From theperspective of file system 805 and application code 801, hardware 803operates in a predictable, consistent manner regardless of which one ormore specific devices it includes.

Including a FEE wrapper function in a computing system allows a filesystem designed for EEPROM devices to communicate seamlessly with anarbitrary FEE device. FIG. 9 illustrates an exemplary block diagram ofcomputer hardware 900 with a file system in communication with a FEEwrapper function according to examples of the disclosure. Hardware 900can include RAM 910 and memory 950. RAM 910 can store a table ofcontents 920 and additional data addressable by bits 934 and bytes 932.In some examples, memory 950 can include a FEE device, wherein datastored in a plurality of blocks 982 and 984 can be addressable byemulated bits 974 and bytes 972.

In some examples, RAM 910 can be faster and more expensive thannon-volatile memory 950. Non-volatile memory 950 can retain data evenwhen the power supply (not pictured) to the hardware 900 isdisconnected, for example. Because RAM 910 and non-volatile memory 950have different advantages and disadvantages, hardware 900 can use bothlevels of memory to have fast performance and inexpensive memory capableof saving data without a connected power supply.

In some examples, a file system can include hardware-agnostic functionsfor developers to call to use the file system, making their codecompatible with a variety of non-volatile memory types. Including a FEEwrapper function (e.g., wrapper 807) in a computing system (e.g.,computing system 800) can allow a file system (e.g., file system 805)itself to call hardware-agnostic functions to operate. For example,memory 950 can be a FEE device including memory addressable in “blocks”,such as blocks 992 and 994. In some examples, a FEE device can emulateEEPROM behavior by providing a mapping between emulated EEPROM addresses(such as bytes 972 and bits 974) to one or more blocks (such as blocks992 and 994), though blocks may have to be read and written (e.g., by afunction included in a FEE library or in a wrapper function) in theirentirety. As an example, block 982 can store a data structure“frontLights” 992 and a first part of a data structure “rearLights” 994.Block 984 can store a second part of “rearLights” 994 and “fogLights”996.

When the file system receives a command to read “frontLights” 992, alldata stored in block 982 can be retrieved by the FEE wrapper functionbecause in some examples, flash blocks of FEE devices may have to beloaded in their entirety. That is, bytes 972 and bits 974 may not beindividually addressable directly from a FEE device included in memory950. In accordance with EEPROM-like behavior (including the ability forthe file system to individually address bytes 972 and bits 974), the FEEwrapper function can output “frontLights” 992 to the file system to beloaded into RAM 910. Although the FEE wrapper function can also loadfrom the FEE device a first part of “rearLights” 994 because it isincluded in block 982, that data may not be output by the FEE wrapperfunction to the file system in response to the file system's request foronly bytes 0x13C and 0x13B. In this way, the file system can input anEEPROM-style read command to the FEE wrapper to read bytes 0x013C and0x013A without specifically requesting to read block 982, for example.

Similarly, although the data structure “rearLights” 994 can be a samesize as “frontLights” 992 (e.g., they can each include two bytes ofdata), “rearLights” 994 can be partially stored in block 982 andpartially stored in 984. When the file system receives a command to read“rearLights” 994, block 982 and block 984 can retrieved from the FEEdevice by the FEE wrapper function. In accordance with EEPROM-likebehavior (including the ability for the file system to individuallyaddress bytes 972 and bits 974), the FEE wrapper function can output“rearLights” 994 to the file system to be loaded into RAM 910. AlthoughFEE wrapper function can also load from the FEE device “frontLights” 992and “fogLights” 996, these data may not be output by the FEE wrapperfunction to the file system in response to the file system's request foronly bytes 0x013A and 0x0139. In this way, the file system can input anEEPROM-style read command to the FEE wrapper to read bytes 0x13A and0x139 without specifically requesting to read data from blocks 982 and984, for example.

Referring again to FIG. 8, by including FEE wrapper 807 in computingsystem 800, a file system 805 can be designed to make a same pluralityof read/write commands to the FEE wrapper 807, regardless of which typesof devices are included in hardware 803. For example, application code801 and file system 805 can be written before a type of hardware 803 isselected. When a type of hardware 803 changes, the FEE wrapper function807 can be updated to include logic to determine a type of hardware 803and make the appropriate function calls to hardware 803 in response toreceived function calls from file system 805, without necessitating anupdated file system.

Application code 801 can interact with file system 805 in a same manneras application code 301 can interact with file system 305, although filesystem 305 can make function calls to hardware 303 while file system 805can make function calls to FEE wrapper 807. Operation of a file systemincluded in hardware 900 will now be described with reference to FIG. 9.According to some examples of the disclosure, hardware 900 can use afile system capable of managing data in RAM 910 and non-volatile memory950. The file system can include a table of contents, of which there maybe a copy 920 saved in RAM 910 and/or a copy 960 saved in non-volatilememory 950. When the table of contents 920 stored in RAM 910 is updated,as will be described below, and then saved to non-volatile memory 950,both copies 920 and 960 can be identical. The table of contents 920stored in RAM 910 can include entries, such as entry 922 that indicatewhere each data structure of the computing system is stored in RAM 910and non-volatile memory 950, which will be described in more detailbelow. Likewise, for example, the table of contents 960 stored innon-volatile memory 960 of hardware 900 can include respective entry962.

Entry 922 in table of contents 920 can include a unique ID 921, anaddress 923 of the data structure in RAM 910, an address 925 of the datastructure in non-volatile memory 950, and the size 927 of the datastructure, for example. Likewise, for example, entry 962 in table ofcontents 960 can include a unique ID 961, an address 963 of the datastructure in RAM 910, an address 965 of the data structure innon-volatile memory 950, and the size 967 of the data structure. Asshown in FIG. 9, for example, “frontLights” is stored at address 0x7EFin RAM 910 and emulated address 0x013CF in non-volatile memory 950.These addresses are reflected in entry 922 in table of contents 910 andentry 962 in table of contents 960. In some examples including one ormore FEE devices functioning as memory 950, the table of contents canfurther include an address of one or more blocks corresponding to anemulated EEPROM-style address 965 of a data structure.

Some example tables of contents 920 and 960 may also include metadata(not pictured) for each entry. The metadata can include a version numberand a time indicating when the entry was last saved to non-volatilememory. Some examples of the disclosure may, additionally oralternatively, have other kinds of metadata for each entry within atable of contents.

In some examples, a table of contents, such as table of contents 920 ortable of contents 960 for example, can also include its own metadata(not pictured). This metadata can include an ID to indicate a locationof table of contents in non-volatile memory, a version indicating thestructure of the table of contents, a time indicating when the table ofcontents was created, and a time indicating when the table of contentswas last saved to non-volatile memory. Some examples of the disclosuremay, additionally or alternatively, have other kinds of metadata for atable of contents.

A file system according to examples of the disclosure can automaticallymanage where in RAM and non-volatile memory to a save data structureonce that data structure is initiated. FIG. 10 illustrates an exemplaryprocess 1000 for initiating a file system and loading or generating atable of contents 920 or 960 for the file system, according to examplesof the disclosure. An application stored on a computing system canexecute a command to initiate a file system (e.g., the command canoriginate in application code). Once the command is received 1010 at thefile system, the computing system can check 1020 non-volatile memory 950for an existing table of contents 960, for example. In some examples, atable of contents 960 and its entries may have been saved tonon-volatile memory 950 before the computing system's power wasdisconnected. In some examples, when a table of contents 960 is found innon-volatile memory 950, it can be moved 1040 to RAM.

To move an existing TOC to RAM 1040, a file system can communicate witha FEE wrapper function to load the correct data, including converting anemulated EEPROM address to one or more blocks of memory of the FEEdevice, as will be described below. A file system can issue a command(1042) to the wrapper function to load data at an emulated EEPROMaddress at which a table of contents is stored. The FEE wrapper functioncan convert (1044) the EEPROM address to a flash address. The FEEwrapper function can also issue a command to a FEE device to load (1046)the requested blocks of memory. The FEE wrapper function can return(1048) to the file system the table of contents. In some examples, theFEE wrapper function can receive additional data while loading the flashblocks including the table of contents 960, but can only return to thefile system the table of contents 960. The file system can copy (1050)the table of contents 960 into RAM 920. In some examples, when no tableof contents is found in memory 950, a new table of contents 910 or 960can be created 1034. Once the table of contents 960 is moved 1040 to RAM910, or table of contents 920 is created 1034 in RAM 910, it can be readand edited by the computing system to manage data, according to examplesof the disclosure.

In some examples, once a table of contents 920 is in RAM 910, thecomputing system can use the file system to manage data. FIG. 11illustrates an exemplary process 1100 for managing a data structureincluding registering an entry 1110, saving an entry 1130, andretrieving an entry 1150 using a file system, according to examples ofthe disclosure. For data to be managed by the file system, it can beregistered 1110 with a table of contents, for example.

In some examples, registering 1110 an entry can include storing an ID921 or 961 of the data structure, its size 927 or 967, and its addressin RAM 923 or 963 and/or its address in memory 925 or 965 in a table ofcontents 910 or 950. In some examples, an application executed by thecomputing system can include a command to register an entry to a tableof contents of a file system. The command can include a unique ID 921 or962 for the entry, the size 927 or 967 of the data structure, and aversion number (not shown), for example. When the command is received1112 at the file system, the entry can be added to the table of contents1114 and managed by the file system according to examples of thedisclosure.

In some examples, space in RAM 910 and non-volatile memory 950 can beallocated for each entry at the time it is registered. In some examples,space in RAM 910 and non-volatile memory 950 can be dynamicallyallocated as needed. In some examples, when an entry is registered tothe table of contents 920 or 960, the entry may not include an address925 or 926 in non-volatile memory 950 until the application codeexecutes a command to perform a save operation 1130 to save thecorresponding data, as described below. Additionally or alternatively,in some examples, data stored in non-volatile memory 950 may not have aRAM address 923 or 963 associated therewith until it is loaded 1150 fromnon-volatile memory 950, as described below. Examples of saving andloading data with a file system according to examples of the disclosurewill now be described.

In some examples, after registering entries, as described above, thefile system can save 1130 registered entries to non-volatile memory 950.Saving data to non-volatile memory 950, as discussed above, can have theadvantages of protecting it in the event of a power outage and/orcreating more space in RAM 910 for data that may need to be edited, forexample. An application executed by the computing system according toexamples of the disclosure can modify data associated with a registeredentry and then execute a command to save the data to non-volatile memory950. The file system can receive 1132 a command to save an datacorresponding to an entry in a table of contents 920 or 960 tonon-volatile memory 950. The file system can in turn send a command 1134to a FEE wrapper to save the data corresponding to the entry at aspecified emulated EEPROM address. In response, the FEE wrapper canconvert 1136 the address to an address of the one or more blocksincluding the specified address. The entry can be saved 1138 to thespecified location without editing or overwriting any other dataincluded in the one or more blocks in which the entry is saved.

In some examples, to write data to a block, the whole block can bere-written. One or more of a FEE library and a FEE wrapper function canbe configured to re-write a block including an updated version of thedata structure for which the save command was received. In a sameoperation, the FEE wrapper can re-write an existing version of one ormore additional data structures stored in the block. The wholere-written block can be saved.

In some examples, an entry may have space allocated for it innon-volatile memory 950 when it is registered. That is, there may bespace in non-volatile memory 950 allocated for data that has not yetbeen saved to non-volatile memory 950, for example. In some examples, anentry may not have space allocated for it in non-volatile memory 950when it is registered. That is, an entry's address 925 or 965 innon-volatile memory 950 may not be included in the table of contents 920or 960 until the data corresponding to the entry has been saved tonon-volatile memory 950, for example.

In some examples, once an entry is registered 1110 with a table ofcontents 920 or 960 and saved 1130 to non-volatile memory 950, the datacorresponding to the entry can be retrieved 1150 from non-volatilememory 950 and loaded into RAM 910. Loading data into RAM 910, asdiscussed above, can have the advantages of quick access and editing,for example. In some examples, an application executed by the computingsystem can retrieve data to be edited or otherwise used by the computingsystem by executing a command. The file system can receive 1152 acommand to retrieve an entry at a specified emulated EEPROM address. Thefile system can in turn send 1154 a command to the FEE wrapper functionto retrieve data at the specified emulated EEPROM address. The FEEwrapper function can convert 1156 the emulated EEPROM address to anaddress of one or more blocks in flash memory including the specifieddata. The FEE wrapper function can retrieve 1158 the data, including anyother data included in the flash blocks including the entry, but onlyreturn the requested data to the file system to be loaded into RAM.

In some examples, an address 923 or 963 in RAM may be allocated for databefore a command to retrieve the entry's data is received at the filesystem. That is, the table of contents 920 or 960 may already include anassigned address 923 or 963 in RAM 910 for an entry before it isretrieved, for example. In some examples, an address 923 or 963 in RAM910 may be allocated for an entry when a command to retrieve the entry'sdata is received. That is, an entry's address 923 or 963 in RAM 910 maynot be included in the table of contents 920 or 960 until the dataassociated with the entry has been loaded into RAM 910, for example.According to examples of the disclosure, an entry can be retrieved aslong as it is registered to the table of contents 920 or 960 and itsdata is saved to non-volatile memory 960. For example, if a computingsystem has not saved or otherwise edited data using its RAM 910 sincepowering on, it can access data saved to non-volatile memory 960 duringa previous use by retrieving it from non-volatile memory 950.

In some examples, when data is being saved to non-volatile memory 950,an interruption such as a power outage or other error can corrupt thedata. In a safety-critical system such as a vehicle ECU, it may beimportant for saves only to occur when there is enough time to reliablycomplete the process uninterrupted, for example. Therefore, someexamples of the disclosure only save data to non-volatile memory 950when a command to save is received from the user or when the systemotherwise detects there is sufficient time to execute the save. In someexamples, to preserve the table of contents 920 and all data currentlystored in RAM 910, everything can be saved to non-volatile memory 950before the power supply (not shown) is disconnected. FIG. 12 illustratesan exemplary process 1200 for saving all entries and the table ofcontents to non-volatile storage using a file system, according toexamples of the disclosure. The file system can receive (e.g., fromapplication code) a command to save 1210 everything, for example. Then,all entries can be saved 1220 to non-volatile memory 950 according tosteps 1130-1138 described with reference to FIG. 11. The table ofcontents can also be saved 1130 to non-volatile memory in a similarmanner, for example. In some examples, steps 1120 and 1130 may beperformed in any order or concurrently according to various examples ofthe disclosure.

To update data stored on a FEE device, whole blocks of flash memory canbe re-written, even when just one data structure of a plurality of datastructures residing on a given block is to be updated. In some examples,a FEE wrapper can include a queue for asynchronous read/writeoperations, thus preventing more than one of these operations fromoccurring at a time to protect data from being inadvertently overwrittenor erased. For example, any one or more substeps of saving 1130 andretrieving 1150 an entry in non-volatile memory can include queuing thesave or load operation. The save or load operation may not commencewhile another save or load operation is taking place. This queuingbehavior can avoid inadvertently overwriting and/or erasing all or partof a data structure. FIGS. 13A-13C illustrate exemplary processes ofstoring data using a wrapper function according to examples of thedisclosure.

FIG. 13A illustrates an exemplary process 1300 for updating a datastructure. A FEE device can receive a command (e.g., from a file system,from application code, or from a wrapper function) to update (1302) afirst data structure residing on a block of flash memory, for example.The block can be retrieved (1304) including the first data structureand, in some examples, additional data not part of the first datastructure. The block can be re-written (1306) including updates to thefirst data structure. The block can then be saved (1308) to the device.Accordingly, the first data structure can be updated and any other datastored on the block can remain in a same state as it was in prior towhen the command to update the first data structure was received at step1302.

FIG. 13B illustrates an exemplary process 1310 for updating multipledata structures residing on a same block according to examples of thedisclosure. A FEE device can receive (e.g., from application code, afile system, and/or a wrapper function) (1312) a command to update afirst data structure residing on a block of flash memory. The block canbe retrieved (1314). Next, the block can be re-written (1316) includingupdates to the first data structure. Meanwhile, the FEE device canreceive (1318) a second command to update a second data structureresiding on the same block. The block, as it exists in an unedited statestored on the device, can be retrieved (1320). Next, the block can bere-written including updates to the second data structure (1322). Theoperation to update the first data structure can continue, saving (1324)the re-written block including updates to the first data structure tothe device. Next, the operation to update the second data structure cancontinue, saving the re-written block including updates to the seconddata structure to the device (1326).

Because the operation to update the second data structure began beforethe operation to update the first data structure was completed, updatesto the first data structure can be inadvertently overwritten duringprocess 1310. Although the updated first data structure can be saved tothe FEE device in step 1324, the re-written block including the updatedsecond data can include the original first data structure because it wasretrieved in step 1320 before the updated first data structure wassaved. Similar issues can arise when performing one or more operationsto load data, for example. In some examples, it can be advantageous tocomplete each save or load before starting a second save or load using aFEE wrapper with an asynchronous read/write queue.

FIG. 13C illustrates an exemplary process for updating multiple datastructures residing on a same block according to examples of thedisclosure. A FEE device can receive (1332) a command to update a firstdata structure residing on a block of flash memory. The block can beretrieved (1334). Next, the block can be re-written (1336) includingupdates to the first data structure. Meanwhile, the FEE device canreceive (1338) a second command to update a second data structureresiding on the same block. Rather than beginning to update the seconddata structure, process 1330 can first complete the operation forupdating the first data structure. The re-written block includingupdates to the first data structure can be saved (1340). The updatedblock can be retrieved (1342). Next, the block can be re-writtenincluding updates to the second data structure (1344). Next, there-written block including updates to the second data structure can besaved (1346). Accordingly, both the first and the second data structurescan be updated, as the updates to the first data structure can bewritten to the block before it is retrieved to write updates to thesecond data structure.

One or more ECUs optionally including one or more of application code, afile system, a wrapper function, and hardware according to examples ofthe disclosure can be incorporated into a consumer automobile. FIG. 14illustrates a block diagram of an exemplary vehicle 1400 including aplurality of ECUs 1420 according to examples of the disclosure. ECUs1420 can include actuator ECUs 1426, indicator ECUs 1428, and other ECUs1430. Vehicle 1400 can further include one or more actuator systems1440, indicator systems 1450, and other systems 1460 operatively coupledto one or more respective ECUs 1420. Actuator systems 1440 can include amotor 1441, an engine 1442, a battery system 1443, transmission gearing1444, suspension setup 1445, brakes 1446, steering 1447, and doors 1448.Indicator systems 1450 can include one or more speakers 1451, one ormore lights 1453, one or more displays 1455, one or more tactileindicators 1457, and one or more mirrors 1449. In some examples, othersystems 1460 can include one or more cameras 1461, navigation 1463,climate control 1465, seating 1467, and one or more safety systems 1469.

In some examples, one or more systems within actuator systems 1440,indicator systems 1450, and other systems 1460 can be operativelycoupled to one or more respective ECUs 1420. For example, a motor ECU(not shown) can control one or more functions of motor 1441. A speakerECU (not shown) can control one or more functions of speaker 1451. Othersystems shown and not shown here can be controlled by one or morerespective ECUs to perform one or more functions. In some examples, oneor more ECUs can include a computing system according to the examplesdescribed with reference to FIGS. 1-13. In some examples, vehicle 1400can include additional ECUs, systems, and other components. For example,vehicle 1400 can include additional computing devices, such asprocessors, controllers, and storage/memory.

Therefore, according to the above, some examples of the disclosure aredirected to a method of managing data in an electronic control unit of avehicle including volatile and non-volatile memory, the methodcomprising: at the electronic control unit of the vehicle: retrieving atable of contents from the non-volatile memory including a plurality ofentries, each respective entry of the plurality of entries including arespective address in the non-volatile memory where respective dataassociated with the respective entry is stored; and in response toreceiving one or more requests associated with a first entry of theplurality of entries, the one or more requests originating inapplication code of the electronic control unit: loading first dataassociated with the first entry from a first address in the non-volatilememory to a second address in the volatile memory, and storing thesecond address in the first entry of the plurality of entries of thetable of contents. Additionally or alternatively to one or more of theexamples disclosed above, the method further includes upon powering onthe electronic control unit, determining whether the table of contentsis stored on the non-volatile memory; and in accordance with the tableof contents not being stored on the non-volatile memory, creating thetable of contents, including in response to receiving a plurality ofentry creation requests originating in the application code of theelectronic control unit, creating a respective entry in the table ofcontents for each of the plurality of entry requests, and assigning arespective address in non-volatile memory to the respective entry in thetable of contents. Additionally or alternatively to one or more of theexamples disclosed above, the method further comprises in response toreceiving one or more initialization requests, originating in theapplication code of the electronic control unit, for each respectiveentry of the plurality of entries in the retrieved table of contents:loading respective data associated with the respective entry from thenon-volatile memory to a respective address in the volatile memory, andstoring the respective address in the respective entry of the pluralityof entries of the table of contents. Additionally or alternatively toone or more of the examples disclosed above, the method furthercomprises in response to receiving one or more shutdown requests,loading data associated with selected entries of the table of contentsfrom the volatile memory to the non-volatile memory. Additionally oralternatively to one or more of the examples disclosed above, the methodfurther comprises in response to receiving a request to load second datafrom the volatile memory to the non-volatile memory, the requestoriginating in the application code of the electronic control unit,determining a hardware type of the non-volatile memory, determining athird address in the non-volatile memory at which to load the seconddata, the third address in a first domain, converting the third addressto a second domain in accordance with the hardware type of thenon-volatile memory, and writing the second data to the non-volatilememory in accordance with the hardware type of the non-volatile memory.Additionally or alternatively to one or more of the examples disclosedabove, a location in the non-volatile memory associated with the thirdaddress in the second domain further comprises third data, and writingthe second data to the non-volatile memory comprises re-writing thethird data. Additionally or alternatively to one or more of the examplesdisclosed above, the method further comprises while performing any oneof determining the hardware type, determining the third address,converting the third address, and writing to the non-volatile memory,receiving a request to load third data from volatile memory tonon-volatile memory, and in response to the request to load the thirddata from volatile memory to non-volatile memory: waiting until writingthe second data to the non-volatile memory is complete, and afterwaiting until writing the second data is complete, determining a fourthaddress in the non-volatile memory at which to load the third data; andwriting the third data to the non-volatile memory.

Some examples of the disclosure are related to a non-transitorycomputer-readable storage medium storing instructions that, whenexecuted by one or more processors of an electronic control unit of avehicle, causes the electronic control unit to perform a method ofmanaging data in the electronic control unit including volatile andnon-volatile memory, the method comprising: at the electronic controlunit of the vehicle: retrieving a table of contents from thenon-volatile memory including a plurality of entries, each respectiveentry of the plurality of entries including a respective address in thenon-volatile memory where respective data associated with the respectiveentry is stored; and in response to receiving one or more requestsassociated with a first entry of the plurality of entries, the one ormore requests originating in application code of the electronic controlunit, loading first data associated with the first entry from a firstaddress in the non-volatile memory to a second address in the volatilememory, and storing the second address in the first entry of theplurality of entries of the table of contents. Additionally oralternatively to one or more of the examples disclosed above, the methodfurther comprises determining whether the table of contents is stored onthe non-volatile memory; and in accordance with the table of contentsnot being stored on the non-volatile memory, creating the table ofcontents, including in response to a plurality of entry creationrequests originating in the application code of the electronic controlunit, creating a respective entry in the table of contents for each ofthe plurality of entry requests, and assigning a respective address innon-volatile memory to the respective entry in the table of contents.Additionally or alternatively to one or more of the examples disclosedabove, the method further comprises in response to receiving one or moreinitialization requests, originating in the application code of theelectronic control unit, for each respective entry of the plurality ofentries in the retrieved table of contents: loading respective dataassociated with the respective entry from the non-volatile memory to arespective address in the volatile memory, and storing the respectiveaddress in the respective entry of the plurality of entries of the tableof contents. Additionally or alternatively to one or more of theexamples disclosed above, the method further comprises in response toreceiving one or more shutdown requests, loading data associated withselected entries of the table of contents from the volatile memory tothe non-volatile memory. Additionally or alternatively to one or more ofthe examples disclosed above, the method further comprises in responseto receiving a request to load second data from the volatile memory tothe non-volatile memory, the request originating in the application codeof the electronic control unit: determining a hardware type of thenon-volatile memory, determining a third address in the non-volatilememory at which to load the second data, the third address in a firstdomain, converting the third address to a second domain in accordancewith the hardware type of the non-volatile memory, and writing thesecond data to the non-volatile memory in accordance with the hardwaretype of the non-volatile memory. Additionally or alternatively to one ormore of the examples disclosed above, a location in the non-volatilememory associated with the third address in the second domain furthercomprises third data, and writing the second data to the non-volatilememory comprises re-writing the third data. Additionally oralternatively to one or more of the examples disclosed above, the methodfurther comprises while performing any one of determining the hardwaretype, determining the third address, converting the third address, andwriting to the non-volatile memory, receiving a request to load thirddata from volatile memory to non-volatile memory, and in response to therequest to load the third data from volatile memory to non-volatilememory: waiting until writing the second data to the non-volatile memoryis complete, and after waiting until writing the second data iscomplete: determining a fourth address in the non-volatile memory atwhich to load the third data; and writing the third data to thenon-volatile memory.

Some examples of the disclosure are related to a vehicle comprising anelectronic control unit, the electronic control unit configured forretrieving a table of contents from the non-volatile memory including aplurality of entries, each respective entry of the plurality of entriesincluding a respective address in the non-volatile memory whererespective data associated with the respective entry is stored; and inresponse to receiving one or more requests associated with a first entryof the plurality of entries, the one or more requests originating inapplication code of the electronic control unit: loading first dataassociated with the first entry from a first address in the non-volatilememory to a second address in the volatile memory, and storing thesecond address in the first entry of the plurality of entries of thetable of contents. Additionally or alternatively to one or more of theexamples disclosed above, the electronic control unit is furtherconfigured for: upon powering on the electronic control unit,determining whether the table of contents is stored on the non-volatilememory; and in accordance with the table of contents not being stored onthe non-volatile memory, creating the table of contents, including: inresponse to receiving a plurality of entry creation requests originatingin the application code of the electronic control unit, creating arespective entry in the table of contents for each of the plurality ofentry requests, and assigning a respective address in non-volatilememory to the respective entry in the table of contents. Additionally oralternatively to one or more of the examples disclosed above, theelectronic control unit is further configured for: in response toreceiving one or more initialization requests, originating in theapplication code of the electronic control unit, for each respectiveentry of the plurality of entries in the retrieved table of contents:loading respective data associated with the respective entry from thenon-volatile memory to a respective address in the volatile memory, andstoring the respective address in the respective entry of the pluralityof entries of the table of contents. Additionally or alternatively toone or more of the examples disclosed above, the electronic control unitis further configured for: in response to receiving a request to loadsecond data from the volatile memory to the non-volatile memory, therequest originating in the application code of the electronic controlunit: determining a hardware type of the non-volatile memory,determining a third address in the non-volatile memory at which to loadthe second data, the third address in a first domain, converting thethird address to a second domain in accordance with the hardware type ofthe non-volatile memory, and writing the second data to the non-volatilememory in accordance with the hardware type of the non-volatile memory.Additionally or alternatively to one or more of the examples disclosedabove, a location in the non-volatile memory associated with the thirdaddress in the second domain further comprises third data, and writingthe second data to the non-volatile memory comprises re-writing thethird data. Additionally or alternatively to one or more of the examplesdisclosed above, the electronic control unit is further configured for:while performing any one of determining the hardware type, determiningthe third address, converting the third address, and writing to thenon-volatile memory, receiving a request to load third data fromvolatile memory to non-volatile memory, and in response to the requestto load the third data from volatile memory to non-volatile memory:waiting until writing the second data to the non-volatile memory iscomplete, and after waiting until writing the second data is complete:determining a fourth address in the non-volatile memory at which to loadthe third data; and writing the third data to the non-volatile memory.

Although examples have been fully described with reference to theaccompanying drawings, it is to be noted that various changes andmodifications will become apparent to those skilled in the art. Suchchanges and modifications are to be understood as being included withinthe scope of examples of this disclosure as defined by the appendedclaims.

1. A method of managing data in an electronic control unit of a vehicleincluding volatile and non-volatile memory, the method comprising: atthe electronic control unit of the vehicle: retrieving a table ofcontents from the non-volatile memory including a plurality of entries,each respective entry of the plurality of entries including a respectiveaddress in the non-volatile memory where respective data associated withthe respective entry is stored; and in response to receiving one or morerequests associated with a first entry of the plurality of entries, theone or more requests originating in application code of the electroniccontrol unit: loading first data associated with the first entry from afirst address in the non-volatile memory to a second address in thevolatile memory, and storing the second address in the first entry ofthe plurality of entries of the table of contents.
 2. The method ofclaim 1, the method further comprising: upon powering on the electroniccontrol unit, determining whether the table of contents is stored on thenon-volatile memory; and in accordance with the table of contents notbeing stored on the non-volatile memory, creating the table of contents,including: in response to receiving a plurality of entry creationrequests originating in the application code of the electronic controlunit, creating a respective entry in the table of contents for each ofthe plurality of entry requests, and assigning a respective address innon-volatile memory to the respective entry in the table of contents. 3.The method of claim 1, the method further comprising: in response toreceiving one or more initialization requests, originating in theapplication code of the electronic control unit, for each respectiveentry of the plurality of entries in the retrieved table of contents:loading respective data associated with the respective entry from thenon-volatile memory to a respective address in the volatile memory, andstoring the respective address in the respective entry of the pluralityof entries of the table of contents.
 4. The method of claim 1, themethod further comprising: in response to receiving one or more shutdownrequests, loading data associated with selected entries of the table ofcontents from the volatile memory to the non-volatile memory.
 5. Themethod of claim 1, the method further comprising: in response toreceiving a request to load second data from the volatile memory to thenon-volatile memory, the request originating in the application code ofthe electronic control unit: determining a hardware type of thenon-volatile memory, determining a third address in the non-volatilememory at which to load the second data, the third address in a firstdomain, converting the third address to a second domain in accordancewith the hardware type of the non-volatile memory, and writing thesecond data to the non-volatile memory in accordance with the hardwaretype of the non-volatile memory.
 6. The method of claim 5, wherein alocation in the non-volatile memory associated with the third address inthe second domain further comprises third data, and writing the seconddata to the non-volatile memory comprises re-writing the third data. 7.The method of claim 5, the method further comprising: while performingany one of determining the hardware type, determining the third address,converting the third address, and writing to the non-volatile memory,receiving a request to load third data from volatile memory tonon-volatile memory, and in response to the request to load the thirddata from volatile memory to non-volatile memory: waiting until writingthe second data to the non-volatile memory is complete, and afterwaiting until writing the second data is complete: determining a fourthaddress in the non-volatile memory at which to load the third data; andwriting the third data to the non-volatile memory.
 8. A non-transitorycomputer-readable storage medium storing instructions that, whenexecuted by one or more processors of an electronic control unit of avehicle, causes the electronic control unit to perform a method ofmanaging data in the electronic control unit including volatile andnon-volatile memory, the method comprising: at the electronic controlunit of the vehicle: retrieving a table of contents from thenon-volatile memory including a plurality of entries, each respectiveentry of the plurality of entries including a respective address in thenon-volatile memory where respective data associated with the respectiveentry is stored; and in response to receiving one or more requestsassociated with a first entry of the plurality of entries, the one ormore requests originating in application code of the electronic controlunit: loading first data associated with the first entry from a firstaddress in the non-volatile memory to a second address in the volatilememory, and storing the second address in the first entry of theplurality of entries of the table of contents.
 9. The non-transitorycomputer-readable storage medium of claim 8, the method furthercomprising: determining whether the table of contents is stored on thenon-volatile memory; and in accordance with the table of contents notbeing stored on the non-volatile memory, creating the table of contents,including: in response to a plurality of entry creation requestsoriginating in the application code of the electronic control unit,creating a respective entry in the table of contents for each of theplurality of entry requests, and assigning a respective address innon-volatile memory to the respective entry in the table of contents.10. The non-transitory computer-readable storage medium of claim 8, themethod further comprising: in response to receiving one or moreinitialization requests, originating in the application code of theelectronic control unit, for each respective entry of the plurality ofentries in the retrieved table of contents: loading respective dataassociated with the respective entry from the non-volatile memory to arespective address in the volatile memory, and storing the respectiveaddress in the respective entry of the plurality of entries of the tableof contents.
 11. The non-transitory computer-readable storage medium ofclaim 8, the method further comprising: in response to receiving one ormore shutdown requests, loading data associated with selected entries ofthe table of contents from the volatile memory to the non-volatilememory.
 12. The non-transitory computer-readable storage medium of claim8, the method further comprising: in response to receiving a request toload second data from the volatile memory to the non-volatile memory,the request originating in the application code of the electroniccontrol unit: determining a hardware type of the non-volatile memory,determining a third address in the non-volatile memory at which to loadthe second data, the third address in a first domain, converting thethird address to a second domain in accordance with the hardware type ofthe non-volatile memory, and writing the second data to the non-volatilememory in accordance with the hardware type of the non-volatile memory.13. The non-transitory computer-readable storage medium of claim 12,wherein a location in the non-volatile memory associated with the thirdaddress in the second domain further comprises third data, and writingthe second data to the non-volatile memory comprises re-writing thethird data.
 14. The non-transitory computer-readable storage medium ofclaim 12, the method further comprising: while performing any one ofdetermining the hardware type, determining the third address, convertingthe third address, and writing to the non-volatile memory, receiving arequest to load third data from volatile memory to non-volatile memory,and in response to the request to load the third data from volatilememory to non-volatile memory: waiting until writing the second data tothe non-volatile memory is complete, and after waiting until writing thesecond data is complete: determining a fourth address in thenon-volatile memory at which to load the third data; and writing thethird data to the non-volatile memory.
 15. A vehicle comprising anelectronic control unit, the electronic control unit configured for:retrieving a table of contents from the non-volatile memory including aplurality of entries, each respective entry of the plurality of entriesincluding a respective address in the non-volatile memory whererespective data associated with the respective entry is stored; and inresponse to receiving one or more requests associated with a first entryof the plurality of entries, the one or more requests originating inapplication code of the electronic control unit: loading first dataassociated with the first entry from a first address in the non-volatilememory to a second address in the volatile memory, and storing thesecond address in the first entry of the plurality of entries of thetable of contents.
 16. The vehicle of claim 15, wherein the electroniccontrol unit is further configured for: upon powering on the electroniccontrol unit, determining whether the table of contents is stored on thenon-volatile memory; and in accordance with the table of contents notbeing stored on the non-volatile memory, creating the table of contents,including: in response to receiving a plurality of entry creationrequests originating in the application code of the electronic controlunit, creating a respective entry in the table of contents for each ofthe plurality of entry requests, and assigning a respective address innon-volatile memory to the respective entry in the table of contents.17. The vehicle of claim 15, wherein the electronic control unit isfurther configured for: in response to receiving one or moreinitialization requests, originating in the application code of theelectronic control unit, for each respective entry of the plurality ofentries in the retrieved table of contents: loading respective dataassociated with the respective entry from the non-volatile memory to arespective address in the volatile memory, and storing the respectiveaddress in the respective entry of the plurality of entries of the tableof contents.
 18. The vehicle of claim 15, wherein the electronic controlunit is further configured for: in response to receiving a request toload second data from the volatile memory to the non-volatile memory,the request originating in the application code of the electroniccontrol unit: determining a hardware type of the non-volatile memory,determining a third address in the non-volatile memory at which to loadthe second data, the third address in a first domain, converting thethird address to a second domain in accordance with the hardware type ofthe non-volatile memory, and writing the second data to the non-volatilememory in accordance with the hardware type of the non-volatile memory.19. The vehicle of claim 15, wherein a location in the non-volatilememory associated with the third address in the second domain furthercomprises third data, and writing the second data to the non-volatilememory comprises re-writing the third data.
 20. The vehicle of claim 15,wherein the electronic control unit is further configured for: whileperforming any one of determining the hardware type, determining thethird address, converting the third address, and writing to thenon-volatile memory, receiving a request to load third data fromvolatile memory to non-volatile memory, and in response to the requestto load the third data from volatile memory to non-volatile memory:waiting until writing the second data to the non-volatile memory iscomplete, and after waiting until writing the second data is complete:determining a fourth address in the non-volatile memory at which to loadthe third data; and writing the third data to the non-volatile memory.